The present invention is related to computer systems and computer implemented processes which allow a user to define representations of software systems. The present invention is also related to computer systems for storing multiple alternate implementations of computer programs. The present invention is also related to computer systems and computer implemented processes for generating computer program code from a high level description of a software system.
The design and specification of software systems has been studied from many perspectives. Research in software architectures has lead to several languages for architectural description of software systems, including representing architectural taxonomies and specific software architectures.
Software development research has provided a variety of approaches to building software systems, including module interconnection languages, open software architectures such as software bus architectures, object oriented programming, coordination languages and application frameworks. An application framework includes an application programming interface and a set of protocols that guide the way calls to the application programming interface should be used inside components. Research in software reuse has also resulted in the development of software schemas such as the Programmer""s Apprentice, and program transformation systems which translate programs between computer programming languages.
Other areas of research in software development include operating systems and concurrent and distributed systems. Additionally, numerous computer related software engineering tools, i.e., automated tools that support various phases of software design and development, also have been developed.
The present invention applies coordination theory to the representation of software systems. Coordination theory focuses on the interdisciplinary study of the process of managing dependencies among activities, in particular, business processes, operation research, organization theory, economics, linguistics, psychology and computer science. Coordination theory has been used as the basis for a representation and design of business processes in a process handbook, as described in PCT publication WO94/19742, published Sep. 1, 1994, also incorporated by reference. This reference does not discuss entities such as ports and resources as described below and how to generate executable code or system configurations from process representations.
Current programming languages and computer system design tools fail to recognize component interaction as a separate design problem, orthogonal to the specification and implementation of the core function of a component. That is, many software components have the built in assumptions about coordination, interoperability and architectural characteristics. Given a set of software components, designers typically either have to modify the code of existing components or have to write additional coordination software that bridges mismatches among components. Such mismatches include low level interoperability mismatches, such as differences in expected and provided procedure names, parameter orderings, data types, calling conventions and other interface mismatches. Another kind of mismatch is an architectural mismatch, such as different assumptions about the architecture of the application in which the components appear. Such mismatches include differences in expected and provided communications protocols, different assumptions about resource ownership and sharing, different assumptions about the presence or absence of particular operating system and hardware capabilities, etc. As design moves closer to implementation, current programming tools increasingly focus on representing components. At the implementation level, software systems are sets of source and executable modules in one or more programming languages. Although modules come under a variety of names and flavors, e.g., procedures, packages, objects and clusters, etc., they are all essentially abstractions for components.
By failing to provide separate abstractions for specifying and implementing interconnection protocols among software components, current programming languages force programmers to distribute such protocols among the interdependent components. As a consequence, code-level components encode, apart from their ostensible function, fragments of interconnection protocols from their original development environments. These fragments translate into a set of undocumented assumptions about their dependencies with the rest of the components in a system. When attempting to reuse components in new applications, such assumptions have to be identified manually and modified, in order to match the new interdependency patterns at the target environment. This often requires extensive modifications of existing code, or the development of additional coordination software.
To this date, there has been no uniform framework for describing the various kinds of component mismatches, or systematic set of rules for dealing with them. Designers generally rely on their own intuition and experience and the problem of component composition is still being confronted in a largely ad-hoc fashion.
The present invention provides a mechanism for easily integrating existing software components into new applications. It is based on a recognition that a computer software system includes interdependent collections of software components. That is, at the architectural level, software components and their interdependencies are two distinct and equally important entities. The software components represent the core functional pieces of an application and deal with concepts specific to an application domain. Interdependencies relate to concepts which are orthogonal to the problem domain of most applications, such as transportation, sharing of resources and synchronization constraints among components.
An architectural design language is provided which has linguistic support for representing and transforming software architecture diagrams. This language enables a clear separation of the core functional pieces of an application, herein called activities, and their interconnection relationships in context of the application, herein called dependencies. The language also supports entity specialization, a mechanism through which software architectures can be described at various levels of abstraction.
In addition, a design handbook of dependency types and associated coordination processes is provided. Such a handbook is based on the observation that many interconnection problems and software applications are related to a relatively narrow set of concepts, such as resource flows, resource sharing, and timing dependencies. These concepts are orthogonal to the problem domain of most applications, and can therefore be captured in an application independent vocabulary of dependency types. Similarly, the design of associated coordination processes involves a relatively narrow set of coordination concepts, such as shared events, invocation mechanisms, and communication protocols. Therefore, coordination processes can also be captured in a design space that assists designers in designing a coordination process that manages a given dependency type, simply by selecting the value of a relatively small number of design dimensions. The design handbook combines the vocabulary of dependencies in a design space of coordination processes. Such a handbook may reduce the specification and implementation of software component interdependencies to a routine design problem, capable of being assisted, or even automated, by computer tools.
A process for constructing and transforming architectural diagrams of software architectures to integrate executable design elements into code modules is also provided. The process involves applying a series of transformations to an architectural description of a target application. This architectural description may be defined in the architectural design language provided above. Generally speaking, the transformation process includes constructing application architecture diagrams, interactively specializing generic activities, interactively managing unmanaged dependencies between the activities using coordination processes from the design handbook, and integrating executable design elements into code modules.
As a result, the architectural design language, design handbook and transformations provide a system which can accurately and completely describe nontrivial applications and facilitate code-level and architectural-level software reuse.
Accordingly, one aspect of the present invention is an architectural description language which represents activities and dependencies between activities as separate entities. Dependencies are managed by coordination processes associated with the dependency. Activities and dependencies are connected through ports which encode interfaces between activities and coordination processes. The language may also represent resources which may be understood as the outputs of activities that are beyond the scope of the defined software system. Each entity, i.e., activity, dependency, port or resource, may also have attributes which are name value pairs, specifying additional information about the entity. Attributes may be inherited. That is, activities and dependencies may be specialized into particular versions of an activity or dependency. The attributes for a particular activity are inherited by its specializations.
Another aspect of the invention is a computer system which allows a user to define a software system specification, or entities thereof, in the architectural description language in terms of activities and dependencies and their interconnections through ports.
Another aspect of the invention is a computer system which permits entities in this architecture description language to be combined.
Another aspect of the invention is a computer system which checks for compatibility of connected entities in the architectural description language.
Another aspect of the invention is a computer system for storing and accessing stored representations in the architectural description language, including specializations and decompositions of selected representations.
Another aspect of the invention is a computer system which receives definitions of a computer system in terms of its activities, dependencies and ports indicating their connections and specializes a description of generic component elements.
Another aspect of the invention is a computer system which receives a definition of a software system in terms of its activities, dependencies and ports and which decouples dependencies which cannot be managed independently of other dependencies to generate another definition of the software system.
Another aspect of the invention is a computer system for storing a library of coordination processes, including a representation of specific computer programs, each of which is a specialization of a process for managing a dependency, such as resource sharing dependencies, flow dependencies and timing dependencies. It should be understood that there are many types of dependencies, of which the following description includes particular examples. The various combinations of one or more of these example dependencies is an aspect of this invention.
Another aspect of the invention is a computer system which generates executable computer program code from specialized generic software component elements described as combinations of activities, and dependencies having ports for interconnection.
Other aspects of the invention include the various combinations of one or more of the foregoing aspects of the invention, as well as the combinations of one or more of the various embodiments thereof as found in the following detailed description or as may be derived therefrom. It should be understood that the foregoing aspects of the invention also have corresponding computer-implemented processes which are also aspects of the present invention. It should also be understood that other embodiments of the invention may be derived by those of ordinary skill in the art both from the following detailed description of a particular embodiment of the invention and from the description and particular embodiment of a system in accordance with the invention.
The various aspects of the invention enable reuse of code-level components. Designers can generate new applications simply by selecting existing components to implement activities, and coordination processes to manage dependencies, independently of one another. The development of successful frameworks for mapping dependencies to coordination processes reduces the step of managing dependencies to a routine one, and enables it to be assisted or even automated by design tools. Overall, new applications can be generated with minimal or no need for user-written coordination software.
The various aspects of the invention also enable reuse of software architectures. Designers can reuse the same architectural description in order to reconstruct applications after one or more activities have been replaced by alternative implementations. A designer simply may semi-automatically remanage the dependencies of the affected activities with the rest of the system. Furthermore, designers may reuse the same set of components in different execution environments by managing the dependencies of the same architectural description using different coordination processes, appropriate for each environment.
The various aspects of the invention also enable insight into software organization alternatives. The description of software applications as sets of components interconnected through abstract dependencies may help designers to structure their thinking about how to best integrate the components together. A design space of coordination processes for managing interdependency patterns may assist them to explore alterative ways of organizing the same set of components, in order to select the one which exhibits optimal design properties.